Network services, such as “web” services, are network-based applications that operate in a distributed computing environment to perform specific tasks in response to client requests. Currently, most such web services are focused on providing a variety of real world services, or information about such services, across the Internet.
For an example, a given web service may be designed to identify the cheapest long distance rates for a given client. In this case, the client may provide various information to the web service such as a client identity, a city and state of residence, which are an indication of typical calling patterns, where the web service will use the information to identify a service provider and/or calling plan that would cost the least for the client based upon the client-provided information. In making the determination as to which service provider and/or calling plan is best for the client, the web service may leverage the resources of one or more other web services, for instance the client may be hosted by one or more long distance service providers (e.g., AT&T™, Sprint™, MCI™,) etc. Specifically, the web service that was called upon by the client may return the best provider/plan for the client relative to other web service providers which offers collected information from those services that is needed to help the client make the provider/plan determination.
During development of such a web service, the web service must be tested to ensure that, once deployed on a network (e.g., the Internet), it will work in the manner intended by the developer. Although such testing could be conducted by actually operating the web service live in the intended operating environment (e.g., the Internet), it is undesirable to do so in that if third party web services are called by the web service under development, charges may be unintentionally incurred (e.g., for initiation of long distance services or for service usage fees). Furthermore, the hosts of the third party web services may become irritated with such “false” requests, particularly if many such requests are made of the third party web services during testing.
Although the underlying code of a web service under development could be rewritten to call web services created for test purposes and controlled by the developer, such a testing solution is disadvantageous. In such a case, the web service code must be modified to conduct the testing, and then modified again once testing has been completed to return the code to its original state (i.e., the code is configured to interact with actual web services in the intended operating environment). Such modification is both time-consuming and expensive. Moreover, given that mistakes can be made in modifying the code after testing is completed, it is possible that glitches or “bugs” may exist in the code at the time of deployment despite positive test results being observed.
As noted above it would be desirable to have a system and method for testing a web service in which the web service is tested in a substantially unmodified state and without the web service calling actual third party web services.